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© Transaction processing system. 

© In a transaction processing system that in- 
cludes a plurality of client processes (40) coup- 
led to a server process (42), the server process 
supports execution of transactions generated 
by the client processes. The server process 
includes, for each client process being served, 
one or more transaction message control 
mechanisms. Each transaction message control 
mechanism includes a named processing 
object that includes a name identifying the 
object. The named processing object also in- 
cludes an input process that receives all trans- 
action request messages naming the object and 
identifying the originating client process. The 
input process dispatches a transaction process 
for each transaction request message received 
from the respective client process. Each trans- 
action process oversees transaction execution 
and receives transaction output. A transaction 
process provides a transaction output message 
for the originating client process. In a non- 
sync'd mode of operation, transaction proces- 
ses may synchronously send transaction output 
messages to client processes. In a synchronized 
mode of operation, one transaction process at a 
time sends output messages under control of 
an output process in the named processing 
object. The transaction message control 
mechanisms provide a bi-directional transac- 
tion message flow between server and client 
processes. 
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The invention relates to transaction processing, and more particularly to a transaction processing system 
of the client/server type in which a client process creates a mechanism in a server process that controls bi- 
directional transaction message traffic between the client and server processes. 

A transaction has been defined as a logical unit of work by C.J. Date in his work, INTRODUCTION TO 

5 DATABASE SYSTEMS . Volume I (Addison-Wesley, September, 1985). Date particularly taught that a trans- 
action in the database context consists of a sequence of operations by which a database is transformed from 
one consistent state to another consistent state. A transaction processing system guarantees that a transaction 
will either complete the transformation of a database into a new consistent state, or return the database to the 
consistent state at which the transaction began. 

10 A particularly useful architecture for implementing transaction processing in distributed systems is the cli- 

ent/server model that is described in H.M. Deitel's OPERATING SYSTEMS (Addison-Wesley, 1990). In this 
model, clients denote service consumers in the form of client processes, while servers are processes that pro- 
vide the services. In a typical database system that provides transaction-based access to a plurality of users, 
users enter database requests through client processes. The client processes engage the server process in 

15 the form of a database management system to service the user request according to a predetermined trans- 
action protocol. 

From the standpoint of client and server processes, transactions may be considered as "objects". As ob- 
jects, transactions encompass the procedures and data necessary to satisfy a user request. As objects, trans- 
actions can be directly manipulated by clients and servers. The preferred mode of handling transaction objects 
20 is by messages that specify a particular type of manipulation. In this regard, a user request for reading records 
from a database may manipulate a transaction by specifying that the transaction must read the database and 
by providing parameters that establish where the reading is to take place, what records are to be read, etc. 
The transaction reports the outcome of the manipulation by returning a response message including the results 
of the operation. 

25 Typically, objects are described by data structures that are referred to as "names". Current techniques of 

object-oriented programming recognize a "named processing object" as an object having a name and including 
one or more procedures. 

A transaction message implies a source and a destination. A current database management system, such 
as the IMS product available from INTERNATIONAL BUSINESS MACHINES CORPORATION, distinguishes 
30 these end points by the use of logical terminals (LTERMs). An LTERM provides a queue where transaction 
output from the IMS product resides. Eventually, the IMS product makes the connection between the queue 
and a physical node that will receive the queued output. In the client/server model, the IMS product is consid- 
ered the server process. Such database systems do not afford a client process with a mechanism to control 
transaction message flow by specifying the source and destination of a transaction message. 
35 Viewed from another aspect, the LTERM capability of the IMS product provides a uni-directional (server- 

to-client) pipeline that can only be manipulated by the server. In this respect, an LTERM suggests the pipe 
structure used in UNIX® systems (UNIX is a registered trade mark of Novell Inc.). Pipes may be objectified 
by names. They provide uni-directional, FIFO data transfer between processes and include the capability of 
interprocess synchronization. Two pipes oriented in opposite directions between client and server processes 
40 can provide bidirectional message flow, but entail two processing objects, only one of which can be manipu- 
lated by the client process. 

Manifestly, the more time a server must spend in transaction message processing, the less efficient it 
will be in processing transactions. Accordingly, there is a need in transaction-based systems of the client/ser- 
ver type to provide a mechanism that will allow any client process to objectify a transaction and to manipulate 
45 the transaction object by messages in a bi-directional message pipeline. Viewed from one aspect the present 
invention provides a transaction processing system comprising: 

a plurality of client processors for generating transaction request messages, each transaction request 
message including a request to execute a transaction and an object name; 

a server process for executing transaction requests contained in transaction request messages from 
50 the client processes; 

an interprocess message exchange facility coupled to the client processes and the server process for 
providing client process transaction request messages to the server process and providing transaction output 
messages to the client processes; 

an input process in the named processing object for receiving all transaction request messages that in- 
55 elude the object name and the identification at the respective client process; and 

dispatch means in the input process for dispatching a transaction process in response to a transaction 
request message, each transaction process dispatched by the dispatch means being for receiving a transaction 
request message and for initiating a transaction for execution. 
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The invention provides a mechanism that can be manipulated as an object by a client process to control 
bi-directionai transaction message traffic between the client process and a server process. The invention al- 
lows a client process to name the mechanism as an object at a server process. The named object (also referred 
to as a "Tpipe") includes the ability to receive transaction request messages and transaction output messages 
5 at the server process and to associate transaction output messages with their ultimate destinations. Thus, the 
association between transaction output and its recipient is not made by a server process but is, rather, left to 
the client process. 

The invention is embodied in both a mechanism and a procedure for bi-directional transport of transaction 
messages between server and client processes. 
w The invention affords flexibility to a transaction processing system of the client/server model in that many 

transaction outputs may simultaneously flow through the same Tpipe. 

The invention allows a client process to create more than one Tpipe, thereby allowing distinctions to be 
made between transactions that occur naturally because of, for example, flow-control and synchronization dif- 
ferences. 

15 The invention relieves the server process of responsibility for coupling a transaction output to an end user. 

The invention provides client processes with control over the output of their submitted transactions. 

In order that the invention may be fully understood a preferred embodiment thereof will now be described, 
by way of example only, with reference to the accompanying drawings in which: 

Figure 1 is a block diagram with a transaction-based, client/server database system; 
20 Figure 2 is a block diagram illustrating the invention in a representative operational environment; 

Figure 3 illustrates the structure of a transaction message; 

Figure 4 is a hybrid block/flow diagram illustrating the operation of the invention according to a first mode; 
Figure 5 is a hybrid block/flow diagram illustrating operation of the invention according to a second mode; 
and 

25 Figure 6 is an illustration of another mode of operating the invention. 

The invention concerns a transaction processing system of the client/server type. An exemplary embodi- 
ment of such a system is illustrated in Figure 1. In Figure 1, a central processor, which may include, for example, 
the 3090/MVS product available from INTERNATIONAL BUSINESS MACHINES CORPORATION, is indicated 
by reference numeral 12. A server process 14 executes in the central processor 12. In the preferred embodi- 

30 ment, the server process comprises a database management system such as the IMS product available from 
INTERNATIONAL BUSINESS MACHINES CORPORATION. The server process is coupled by a communica- 
tions facility 16 to a peripheral processor 18 that executes a client process 19. Other peripheral -processors 
20, 21 may be coupled to the communication facility 16 by way of a node 24. The server and client processes 
14 and 19 include respective communications interfaces 25 and 26 that implement an appropriate communi- 

35 cation protocol to support transfer of information between the processes. Such architecture also characterizes 
communications between any client process and the server process 14. (In the invention, client processes may 
execute at virtually any transaction processing system location. Thus, a client process can be located at a per- 
ipheral processor 18, 20. 21, for example, at a node such as 24, and in the central processor 12). 

The server process 14 supports transaction processing that affords client processes with the ability to 

40 access one or more databases such as the databases 27 and 28, The server process includes a database 
management system (DBMS) 29 that has at least a transaction manager 31 and a database manager 32. One 
or more application processes 33 and 34 execute to support user requests for database access. Thus, if a user 
access request is entered at the peripheral processor 18, the client process 19 executes, preparing a trans- 
action request to implement the access requested by the user. The transaction request is sent via a message 

45 to the central processor 12 and delivered to the server process 14. Transaction requests are passed to the 
transaction manager 31 through an input queue 35. The transaction manager evaluates a transaction request, 
dispatches a transaction process to execute the request via one of the applications 33, 34. Output for trans- 
action requests is queued at 36 and passed through the communications interface 25 and the communications 
facility 16 to the respective requesting client processes. 

so As will be appreciated by those skilled in the art, the client/server model of Figure 1 is application specific 

in that it incorporates a structured communication facility which may comprise, for example, a network to in- 
terconnect client and server processes. The invention is not intended to be limited to such a structure. Indeed, 
the invention does not contemplate any specific communications control mechanization. It is concerned es- 
sentially with the control of message traffic between client processes and a server process, no matter where 

55 the processes are located. 

The invention is illustrated in Figure 2 in the context of a client process 40 in a plurality of client processes 
and a server process 42. The client process 40 receives user requests that it structures into transaction request 
messages and provides to the server process 42. The client and server processes 40 and 42 implement trans- 
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action processing according to a transaction protocol that may be selected according to implementation re- 
quirements. 

The invention invests the client process 40 with the ability to control transaction message traffic through 
one or more transaction message control mechanisms ('Tpipes"). The Tpipes are named processing objects 
5 located in the server process 42. Each Tpipe data structure has an input process (PI) with associated queue 
(PIQ), an output process (PO) with associated queue (POQ), and a chain of dynamically created (and deleted, 
when done) transaction processes ((Tprocess) that are created and dispatched for processing transactions. 
Thus, each Tpipe is a data structure having a name that can be referred to in the interface between the client 
and server processes 40 and 42. The inventors contemplate that the Tpipes of the invention would be provided 
10 in a component of the server process 42 that corresponds essentially with a transaction manager. 

In Figure 2, a server Tpipe process 43 uses a hash structure 44 to access a Tpipe 45 having a data field 

46 containing the name of the Tpipe (TpipeN), an input process 47, and an output process 48. The input process 

47 includes the capability of dispatching transaction processes such as the transaction process 50. Each trans- 
action process 50 that is dispatched by the input process 47 has the ability to parse and manipulate messages. 

15 A dispatched transaction process will forward a transaction request to the server process for execution. In this 
respect, the transaction process 50 includes logic for determining an application, such as the application 52. 
which will provide the processing to execute the transaction and which exchanges transaction data with the 
transaction process 50 by way of, for example, input and output queues 55 and 56. The transaction processes 
are also endowed with the ability to communicate transaction output and responses by message to client proc- 

20 esses. 

In operation, the client process 40 responds to a user request by assembling a message 58 having a plur- 
ality of fields. In a first message field 59, the message is denoted as a transaction message. The name of the 
Tpipe which is to receive and process the message 58 is specified in a field 60. A mode field 61 is provided 
in the message to indicate the mode of operation for the named Tpipe. Afield 63 included in the message 58 

25 containing routing information so that the transaction output can be routed to the originating client process. 

Assume that the message field 60 names TpipeN. The server Tpipe process manager 43 will direct the 
message 58 to the input process 47 of TpipeN. The input process 47 will identify the type of transaction in the 
field 59, determine a mode of Tpipe operation in response to the field 61, set a mode flag 64, and dispatch a 
. transaction process 50 for execution of the requested transaction. In dispatching the transaction process 50, 

30 the input process 47 passes to the transaction process the type of transaction and all data necessary to control 
transaction execution, and identifies the client process 40. Since the transaction process 50 is part of the 
named processing object 45. it references its activities to the processes in TpipeN. When the transaction is 
completed, the transaction process checks the mode flag 64. According to one setting of the mode flag 64, 
the transaction process constructs a message that is returned to the client process asynchronously with re- 

35 spect to any other transaction process dispatched by the input process 47. According to another mode setting, 
the transaction process 50 returns the transaction response to the client process under control of the output 
process 48, which synchronizes transaction output among all of the transaction processes dispatched by the 
input process 47. 

According to the invention, every Tpipe named by the client process 40 is reserved for its exclusive use. 

40 Further, the client process may name more than one Tpipe in order to provide a variety of transaction message 
control modes that support particular modalities of transaction message processing. For example, a client proc- 
ess may reserve TpipeY for recoverable message processing, for which case TpipeY would be set to a syn- 
chronous mode of operation whereby transaction output is provided under the control of the output process 
of TpipeY. The same client process may set TpipeX to a non-asynchronous mode for use by transactions that 

^5 do not require message recovery. 

The format of messages transferred between the client and server processes according to the invention 
is illustrated in Figure 3. Each message includes a multi-field structure in which successive sections include 
fields for message control information, transaction state data, and application process data. 

The message control information section includes message type and Tpipe name fields. The message 

50 type field is used to indicate transaction input to the server process. The Tpipe name Held names a Tpipe which 
will be responsible for controlling the message at the server process. The synch field in the state data section 
is used to set the mode flag at the named Tpipe. Preferably, the modes are referred to as Commit Modes, with 
Commit Mode 0 indicating that transaction response is to be committed at the server process before being 
sent to the client process. Commit Mode I permits a transaction response to be sent to the client process before 

55 it is committed at the server process. The state data section also provides token fields that denote the origi- 
nation and destination of a message. The application data section names the transaction to be executed, which 
implies the application process that is to be used for transaction execution. This section also provides all of 
the data necessary to initiate the transaction. 
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With reference now to Figures 2 and 4 and to Tables l-lll, the operation of the invention in Commit Mode 
I will be explained. Tables l-lll are pseudo-code descriptions of logic for, respectively, the server Tpipe process 
43, the Tpipe input process (PI), and a transaction process (Tprocess). The mode of operation for Commit Mode 
I is referred to as non-sync'd Tpipe. Inthenon-sync'd Tpipe mode of operation, all Tprocesses control thesend- 
5 ing of the transaction response messages to the client process. Consequently, the output process (PO) is not 
used. The flow transactions and output through a non-sync'd Tpipe is illustrated in Figure 4. The order and 
explanation of non-sync'd operation is as follows: 

1 . The client 40 sends a transaction message for transaction x as an input to the server process 42. 

2. The transaction message is inspected by the server Tpipe process 43 whose logic is described in Table 
10 I. The server Tpipe process 43 verifies the presence of a Tpipe name in the message, consults the hash 

table 44 to determine whether the Tpipe has been named for the client process 40. If the name is not in 
the table, the Tpipe is created and its name is added to the hash table 44 for the client process 40. The 
transaction message is then enqueued to the input process ("PI") and PI is scheduled to run. Once a Tpipe 
has been created, it will remain linked by the hash table 44 to the client for which it was created for the life 
15 of the server process. 

3. PI takes the transaction message from its queue and dynamically creates a Tprocess ("Tprocess x") 
for transaction x. 

4. Tprocess x for transaction x is dispatched by PI to process the transaction. 

5. Tprocess x submits the transaction to the named application 52 where it may be enqueued at 55. 

20 6. The application 52 then provides through its output queue 56 a transaction output message to Tprocess 

x. 

7. Tprocess x then takes the transaction output message and processes it as required for return to the 
client process 40. 

8. Tprocess x then sends the transaction output message to the client processor 40. If more than one output 
25 message is required for transaction x, the output messages are enqueued on Tprocess x for transmission 

for the client process. Assuming that the client acknowledges messages, when all transaction output mes- 
sages for transaction x have been acknowledged by the client, Tprocess x will be deleted. 
Figure 5 illustrates message flow with a sync'd Tpipe operating in commit mode 0. In this regard, the in- 
vention contemplates a need for sync'd Tpipes in order to resynchronize processing if either the client process 
30 or the server process terminates abnormally. 

For example, consider the scenario where a client process sends a transaction request message to the 
server process with a request for an acknowledgement. Assume that the transaction protocol requires the ser- 
ver to log the requested transaction and enqueue it prior to sending the acknowledgement to the client process. 
If the server process crashes before the acknowledgement is sent, both the client and server processes need 
35 to resynchronize by, for example, an exchange of sequence numbers. With ^synchronization, the client proc- 
ess might assume that the transaction was not received by the server process, in which case the client process 
may attempt to send the transaction a second time. If the transaction is enqueued a second time at the server 
process, this may result in an unacceptable condition such as where the same debit is made twice to an ac- 
count. In order to avoid this, the server process would, with reference to its log during resynchronization, inform 
40 the client process that the transaction was successfully received. In this case, the client would treat the infor- 
mation as an acknowledgement. 

In the foregoing scenario, it would be necessary for the client and server processes each to maintain a 
copy of the last sent message and a record of the last received message in order to support resynchronization. 
This requires that all sending operations be properly serialized at the server process in that no message may 
45 be sent until an acknowledgement has been received for the previous sent message. Relatedly, all sent and 
received messages must be enqueued. This is accomplished in the invention by funneling all output messages 
through the output process in the sync'd mode of operation. 

For a sync'd Tpipe, the output queue (POQ) that is controlled by the output process (PO) is used. Any Tpro- 
cess with a transaction output message in a sync'd mode Tpipe queues for permission from the output process. 
so When the output process grants permission to a Tprocess, only that Tprocess is allowed to send transaction 
output messages to a client process. 

The flow of transactions and output through a sync'd Tpipe is illustrated in Figure 5 and described as fol- 
lows: 

1. The server Tpipe process receives a transaction request message containing transaction x. 
55 2. The server Tpipe process notices that Tpipe A has been named for the transaction and attempts to locate 

that object. If not found, the object is dynamically created and entered into the hash table 44 for the re- 
questing client process where it remains for the life of the server process. 

3. The input process, PI, takes the transaction request message and dynamically creates a Tprocess for 

5 
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transaction x. This Tprocess is denoted as Tprocess x. 

4. Tprocess x is created and dispatched by PI to process transaction x. 

5. Tprocess x submits the transaction to the application process where it may be enqueued. 

6. The application process then provides an output in a transaction response message to Tprocess x. 

5 7. Tprocess x takes the transaction response message and formats it as required by the relevant commu- 

nication protocol. 

8. Tprocess x enqueues a request token on POQ. 

9. PO for Tpipe A returns permission to Tprocess x. Tprocess x is now the only Tprocess for Tpipe A who 
may send messages to the client process. 

10 10. Tprocess x sends transaction output messages to the client process and notifies the PO for Tpipe A 

when message transmission is completed. Now, the PO for Tpipe A may grant permission to another Tpro- 
cess to begin sending transaction output messages. When all the transaction output messages for trans- 
action x have been sent, Tprocess x is deleted. 

The following tables present pseudo-code descriptions of the logic for the components shown in Figures 
15 4 and 5. Table I illustrates the server Tpipe process that receives transaction request messages, verifies Tpipe 
identification, and directs messages that include client process transaction requests to appropriate Tpipes. 

Table II illustrates the logic for a Tpipe input process (PI). Implicit in this logic the ability to identify ac- 
knowledgement (Ack) response from a client process in the sync'd mode of operation. As will be evident from 
inspection of Table II, the output process (PO) in the sync'd mode of operation signals when a Tprocess has 
20 sent an output message and is awaiting an acknowledgement. The logic also illustrates the ability of PI to create 
and change Tprocesses as necessary to service transaction requests for the client process. 

The Tprocess logic for non-sync' d operation is illustrated in Table III. This logic synchronizes the Tprocess 
with an application for receipt of output messages and with the client process by way of acknowledgement of 
output messages. 

25 Table IV gives the logic for a Tpipe output processor (PO), which functions essentially as an output service 

that must be output bid for by Tprocessors. 

The logic for Tprocess in a sync'd Tpipe is given in Table V. In a sync'd Tpipe, a Tprocess logs transactions 
upon receiving them from the PI, retains the exclusive service of PO for all output messages generated for a 
transaction, and logs all output messages. 

30 Figure 6 illustrates an industrial application incorporating a mode of operation for the invention. In this ap- 

plication, a mainframe computer 80 in the form of a 3090/MVS system executes an IMS database access sys- 
tem 82 that is conventionally coupled to applications 83 and 84. The IMS system 82 operates as a server proc- 
ess and incorporates the Tpipes logic of the invention. The IMS system 82 is a server process that provides 
services to client processes in the form adaptors 86 and 87 that communicate with IMS system 82 by way of 

35 the MVS XCF interprocess communication facility 89. The MVS XCF product is available from INTERNATION- 
AL BUSINESS MACHINES CORPORATION and is described, for example, in the Application Development 
Guide: ADG Authorized Assembler Language Programs (publication GC 28-1645) published by INTERNA- 
TIONAL BUSINESS MACHINES CORPORATION. The adapters 86 and 87 are each connected to one or more 
processes 90-93 to afford users the ability to access one or more databases through IMS system 82. Such 

40 processes may be located in remote processing locations such as terminals and may also be located in the 
same processor as the server process. 



45 



50 



55 



6 



8NS0OCID: <EP 0674260A2_I_> 



EP 0 674 260 A2 



TABLE I 

Pseudocode for Server Tpipe Process 43, Fig. 2 

Receive Client's transaction (via XCF or any other 
Transport mechanism). 

Verify that Tpipe name is specified in the transaction. 

Look up Tpipe name in hash table of Tpipe' s. 

If Tpipe does not exist then 

Create the Tpipe and add it to the Tpipes hash table. 
End if 

Enqueue the transaction to the Tpipe* s PI process and 
schedule that PI to run. 

Wait for another transaction. 



TABLE II 

Pseudocode for Input Process 47, Fig. 2 

Receive data on the input queue( PIQ). 

If data is a transaction then 
If Sync'd Tpipe then 

If PO is waiting for an Ack then 
Reject the transaction. 
Go to WAIT logic. 
Endif 
Endif 

Create a Tprocess for the transaction and chain 

it to the list of existing Tprocesses for the Tpipe. 

Schedule the Tprocess to run. 



Elseif data is an Ack from a 
If Sync'd Tpipe then 

If PO is NOT waiting for 
Reject the Ack. 
Go to WAIT logic. 
Else 

Notify the PO that its 
This will cause the PO 
Go to WAIT logic. 
Endif 
Endif 



Client then 
an Ack then 

expected Ack has arrived, 
to wake up and run. 



Locate the Tprocess who is awaiting the Ack and 
notify him that his expected Ack has arrived. 
This will cause the Tprocess to wake up and run. 

Elseif data is a command then 

Process the command 
Else 

Reject the data. 
Endif 

WAIT for more data on the PIQ. 
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TABLE III 

Pseudocode for Tprocess in Non-Sync' d Mode 

Initial processing: A transaction message has been received 
from the PI. 

Enqueue the transaction to the Server application. 
LOOP : WAIT for a notification. 

Wake up as a result of a notification. Either the PI 
is giving an Ack, or a Server application 
is giving output message. 

If notification is for an Ack, then 

If another output message enqueued then 

Send the output message to the Client. 
Elseif no more expected output messages, then 

Delete yourself. 
Endif 

Elseif notification is for an application output message, 
then 

Send the output message to Client. 
Endif 

Go to LOOP to wait for Ack. 



TABLE IV 

Pseudocode for Output Process (PO) in Sync ' d Mode 

Receive Tprocess X's request on the POQ queue. 

Mark PO as giving up control to Tprocess X. 

Notify Tprocess X that he is now in control of output 
processing. This will cause X to run. 

35 Main Wait 

If Tprocess relinquishes control of PO then 

Get next request on the POQ and go to beginning. 

Elfseif PI has given Ack to PO then 

Mark Tprocess as no longer waiting for an Ack. 
40 Notify Tprocess that his Ack has arrived. 

Go to Main wait 

Endif 
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TABLE V 

Pseudocode for Tprocess in Sync'd Mode 

Initial processing: A transaction has been received from 
the PI. 

Log the transaction. Include Client's transaction sequence 
number in che log record. 

Enqueue the transaction to the Server application. 

LOOP: WAIT for a notification. 

Wake up as a result of a notification. Either the PI is 
giving an Ack, or a Server application is giving output 
message (when no other output message processing is taking 
place. I.e. if output message processing is in process, 
then the application will only enqueue the message to the 
Tprocessor ) 

If notification is for an Ack f then 

If another output message enqueued then 

Send the output message to the Client. 
Elseif no more expected output messages, then 

Notify PO to relinquish control of output processing. 

Delete yourself. 
Endif 

Elseif notification is for an application output message, 
then 

Enqueue PO-control request to POQ and WAIT for PO to 
give us this control. 

Log output message with Tpipe's output sequence number. 
Send the output message to Client. 
Indicate in PO that he is now expecting an Ack. 
Endif 

Go to LOOP to wait for Ack. 
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Claims 



1 . A transaction processing system comprising: a plurality of client processes for generating transaction re- 
quest messages, each transaction request message including a request to execute a transaction and an 

40 object name; 

a server process for executing transaction requests contained in transaction request messages 
from the client processes; 

an interprocess message exchange facility coupled to the client processes and the server process 
for providing client process transaction request messages to the server process and providing transaction 
45 output messages to the client processes; 

an input process in the named processing object for receiving all transaction request messages 
that include the object name and the identification at the respective client process; and 

dispatch means in the input process for dispatching a transaction process in response to a trans- 
action request message, each transaction process dispatched by the dispatch means being for receiving 
50 a transaction request message and for initiating a transaction for execution. 

2. A transaction processing system as claimed in claim 1 further comprising: 

routing means in the server process for routing transaction request messages according to proc- 
essing object names contained in the transaction request messages; 
55 a plurality of transaction message transport mechanisms in the server process, wherein each 

transaction message transport mechanism includes a named processing object that includes an object 
name identifying the named processing object and an identification of a respective client process. 
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3. A transaction processing system as claimed in any of claims 1 or 2, wherein the transaction message 
processes dispatched by the dispatch process provide transaction output messages. 

4. A transaction processing system as claimed in any of the preceding claims wherein the named processing 
object further includes an output process for serializing provision of transaction output messages for the 
respective client process. 

5. A transaction processing system as claimed in claim 4, wherein the output process includes means for 
enabling one transaction process to provide a transaction output message while preventing all remaining 
transaction processes dispatched by the dispatch means from providing transaction output messages. 

6. A transaction processing system as claimed in claim 4, wherein the output process includes means for 
queueing transaction output messages. 

7. A method of operating a transaction processing system including a plurality of client processes, a server 
process, a message exchange facility coupled to the plurality of client processes and to the server proc- 
ess, and a plurality of transaction message transport mechanisms in the server process, wherein each 
transaction message transport mechanism includes: 

a named processing object that includes an object name identifying the transaction message trans- 
port mechanism and an identification of a respective client process; 

an input process included in the named processing object; and means in the input process for dis- 
patching processes; 

the method comprising the steps of: 

generating transaction request messages in client processes of the plurality of client processes, 
each transaction request message including a request to execute a transaction, an object name, and an 
identification of a client process which generated the transaction request message; 

providing transaction request messages from client processes to the server process through the 
message exchange facility; 

in the server process, routing a transaction request message to a respective transaction message 
transport mechanism that is linked to a named processing object including a name contained in the mes- 
sage and a field identifying the originating client process; and 

in the respective transaction message transport mechanism, dispatching a transaction process for 
executing a request in the transaction request message. 

8. A method as claimed in claim 7, wherein transaction processes dispatched by the transaction message 
transport mechanisms provide transaction output messages. 

9. A method as claimed in claim 8, wherein said each transaction message transport mechanism further 
includes an output process in the named processing object, the method further including the step of, in 
said each transaction message transport mechanism, the output process serializing the provision of trans- 
action output messages for the respective client process. 

10. A method as claimed in claim 9, wherein the step of serializing includes enabling one transaction process 
to provide a transaction output message while preventing all remaining transaction processes dispatched 
by each transaction message transport mechanism from providing transaction output messages. 

11. A method as claimed in claim 9, wherein the step of serializing includes queueing transaction output mes- 
sages. 

12. A method for grouping transaction messages in a transaction processing system including a plurality of 
client processes and a server process coupled to the plurality of client processes for executing client-ini- 
tiated transactions, a method for grouping transaction messages, the method comprising the steps of: 

sending a transaction request message from a respective client process to the server process, the 
transaction request message including a field identifying the respective client process and an object 
name; 

in the server process, creating a named processing object in response to the transaction request 
message, the named processing object including the object name and identifying the respective client 
process; 
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activating an input process in the named processing object; 

providing all transaction request messages from the respective client that include the object name 
to the input process; and 

for each transaction request message received by the input process, dispatching a transaction 
process by providing the transaction request message to the transaction process for processing a trans- 
action requested by the transaction request message. 

A server apparatus for use in a transaction processing system, comprising: 

a message facility for receiving transaction request messages from client processes; 

means for creating a named processing object in response to a client process transaction request 
message, the transaction request message including a field identifying a respective client process and 
a name identifying the named processing object; 

an input process included in the named processing object and coupled to the message facility for 
receiving all transaction request messages from the respective client process that include the name iden- 
tifying the named processing object; and 

dispatch means in the input process for creating and dispatching a transaction process and for pro- 
viding a transaction request message to the dispatched transaction process for processing a transaction 
requested by the transaction request message. 

A client apparatus for use in a transaction processing system, including: 
means for receiving a plurality of transaction requests; 

means for generating transaction request messages addressed to a server process, each trans- 
action request message being generated in response to a respective transaction request and including: 
a first field identifying a requested transaction; and 

a second field for naming a processing object in a server apparatus, the processing object including 
an object name identifying a server transaction message processing mechanism and the client process; 

means for receiving transaction output messages form a server process and associating each 
transaction output message with a transaction request of the plurality of transaction requests. 

In a server apparatus for use in a transaction processing system, the server apparatus having means for 
coupling to a pluralityof client processes for executing client-initiated transactions, a method for grouping 
transaction messages, the method comprising the server apparatus-executed steps of: 

receiving a transaction request message, the transaction request message including a field iden- 
tifying a respective client process and an object name; 

creating a named processing object in response to the transaction request message, the named 
processing object including the object name and identifying the respective client process; 

activating an input process in the named processing object; 

receiving a plurality of transaction request messages; 

providing all transaction request messages in the plurality of transaction request messages that 
include the object named to the input process; and 

for each transaction request message received by the input process, dispatching a transaction 
process by providing the transaction request message to the transaction process for processing a trans- 
action requested by the transaction request message. 
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(57) In a transaction processing system that in- 
cludes a plurality of client processes (40) coupled to a 
server process (42). the server process supports exe- 
cution of transactions generated by the client process- 
es. The server process includes, for each client process 
being served, one or more transaction message control 
mechanisms. Each transaction message control mech- 
anism includes a named processing object that includes 
a name identifying the object. The named processing 
object also includes an input process that receives all 
transaction request messages naming the object and 
identifying the originating client process. The input proc- 
ess dispatches a transaction process for each transac- 
tion request message received from the respective cli- 
ent process. Each transaction process oversees trans- 
action execution and receives transaction output. A 
transaction process provides a transaction output mes- 
sage for the originating client process. In a non-syne'd 
mode of operation, transaction processes may synchro- 
nously send transaction output messages to client proc- 
esses. In a synchronized mode of operation, one trans- 
action process at a time sends output messages under 
control of an output process in the named processing 
object. The transaction message control mechanisms 
provide a bi-directional transaction message flow be- 
tween server and client processes. 
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